%This chapter introduces the main concepts and background about what this thesis is based on




%\documentclass[oneside]{dit-phd-thesis}
%\usepackage{listings}

%\begin{document}

% manually assign it chapter 2
%\addtocounter{chapter}{1}



% todo add glossary? and def in ch1


\chapter{Literature review: Background of the research} 
The domains that are involved in this thesis span across electronic health
records, clinical terminologies, ontologies and more.  
At the heart of the semantic interoperability
problem is the issue of having different representations of clinical information. Although the
information in each information system may appear valid and meaningful, it is problematic for
different systems to communicate
without creating an interchangeable format that can be used across systems. However, the
nature of clinical information makes an interchangeable format difficult to agree upon. The
communication of clinical information refers to the exchange of large amount of clinical data that
are generated by information systems such as Hospital Information Systems (HIS), Patient Data Management
Systems in acute care units, Laboratory Information Systems (LIS), GP
clinic systems and other clinical systems. 
%search & replace 'and the likes'
This and related issues form a background to this thesis. Before describing this background, this
chapter presents the relevant concepts from the literature by the following topics:


\begin{enumerate} 
  \item Information models of EHR standards and the two-level modelling approach
  \item Clinical terminologies, ontology and SNOMED-CT 
  \item Integration of EHR systems and clinical terminologies 
\end{enumerate}


%todo--organisation of the chapter
%This chapter is organised as follows: the [ref] section discuss the state of art in .. .. 



\section{Exchange of clinical information}
\label{sec:info-exchange}
%copied from transfer report The goal of semantic interoperability in the e-health domain, is an
%elusive but worthwhile one that both the industry and the research community keep pursuing. 
Achieving semantic interoperability of clinical information systems
has been an on-going effort with the aim of 
delivering better healthcare. System integration problems and
mis-interpretation of information during data exchange between heterogeneous systems are major
issues in the current e-health environment \parencite{dipak2006bottomup,dipak2009org}. A standardised and secure mechanism 
to share and exchange commonly
understandable health information is a pre-requisite for Electronic Health Record
(EHR) systems. An Electronic Health Record is not merely a digital
replacement of the paper records but also an approach that utilises a sharable and reusable data
model to promote common understanding between users of different systems that exchange health
records. The ISO document ``Health informatics -- Electronic health record -- Definition, scope and
context'' has described the definition and characteristics of what is considered a highly
sharable electronic health record, an ``Integrated Care EHR'' (ICEHR) \parencite{iso/tr20514}. The
healthcare communities have been calling out for a well integrated EHR because it is well suited for
shared-care that are delivered by multi-disciplinary professionals. 

There are a number of international standards which aim to improve the interoperability
between EHR systems 
and integrate distributed data sources to form a reliable record
\parencite{dipak2006ehrstds,dipak2006bookch,dogac2005ehrstdsurvey,dogac2006ehrrev}. 
Each of these standards provides a specification of an information model that can be used to
record health information. 
%The heterogeneity is not limited to information models.
% def 'system' carefully in ch1

Different architectural approaches are also adopted by major EHR standards. There has been active
research and competition in order to provide a flexible and appropriate information model to record
clinical information among international organisations.  Meanwhile the effort to produce standard
clinic thesauruses leads to the development of clinical terminology systems. A \emph{clinical
terminology}
is the vocabulary of clinical terms that defines phenomena and health-related concepts
\parencite{keizer2000typology,cimino1996review,cornet2008forty}.
When exchanging health related information, the data quality of information recorded
in EHR can be improved by referencing unambiguous concepts from terminology systems. These concepts
exist as codes or terms in various EHR related applications. Terminology systems are often developed
separately by clinical domain experts who model and build codes that can be used for encoding health
information. 


% todo--interesting paper by rosenbloom
%Clinical data communication is critical to healthcare systems that connect health professionals
%with patients.  
%Two important components of
%a large clinical information eco-system are the electronic health record and the clinical
%terminology \parencite{rosenbloom2006interface}.





%At lower level, the infrastructure supports data communication between medical
%devices with more sophisticated systems. For example, There exist technical
%%ref to iso LISA device messaging standard
%standards that define how medical devices should communicate with an external computer system such
%as [ref].  
%Higher level of
%communication involves clinicians and other health professionals who rely on meaningful clinical
%information to make clinical decisions. To fulfil this requirement, a number of standards have been
%developed to provide solutions to solving the problem of communication. 


%todo--maybe move these 2 subsections to chapter1?




\subsection{Electronic health record} 

Prior to communicating clinical information, clinical data
exist in many computer systems that operate in the healthcare environment such as the radiology
information system, cardiology information system, laboratory information system, and patient
administration system. Electronic health record, 
%presume EPR,EHR has been introduced
which was introduced in the first chapter, is a solution to address the information
``silo'' problem of these systems, which has been described as a difficulty of system integration
and information communication. The EHR has a role of record-keeping and communicating clinical
data across different sites in a distributed healthcare environment. Clinical data relating to
healthcare activities and medical records of patients are not stored in a centralised manner, in contrast to an
information system that operates in single site such as the radiology department of a hospital. The
purpose of a shared integrated care health record is to enable EHR compliant systems to communicate
and share clinical information. As introduced in section \ref{sec:introback}, an influential ISO 
technical report \parencite{iso/tr20514} has specified the
characteristics of the electronic health record and envisioned the future realisation of a modern
EHR. A number of EHR standards that represent both mature technology and innovations have emerged
over the time. The following state of art EHR standards will be described in section \ref{sec:2lvlehr}.
\begin{itemize} 
  \item Specifications by the openEHR foundation 
  \item ISO EN13606 part1-5 EHR standard 
  \item HL7 version 3 standards 
\end{itemize}
The core parts of 
these standards describe the information model of an EHR, which governs the structure of
communicated information. Another key component of building interoperable clinical systems is the
use of standard clinical terminology. The next section gives an overview of clinical terminology.




\subsection{Clinical terminology} 

Clinical terminology provides a `vocabulary' of clinical healthcare terms or
concepts \parencite{mccray2006conpt} to be used in a clinical setting. The main reason for defining these medical concepts 
and assigning codes or
terms is to enable the machine processing of encoded health information. There are many types of
terminological resources and coding schemes that have been developed over the years
\parencite{bodenreider2008bioterm, chute1998copernican, chute2000termhist}. 
In the scope of this work clinical terminology can be roughly classified into three types. 
% todo may need to find ref for this
The simplest kind is a
\emph{term-set} or \emph{code-set} which holds a 
list of commonly acknowledged terms/codes and their explanation in human
readable format. For example an `M' represents the description of the patient's sex `male'. The
second type is a \emph{clinical classification} which organises clinical phenomena into hierarchies
and categories such as diseases and
symptoms. The International Classification of Diseases 
(ICD) is an example of this type of terminology. 
Within this type of terminology system there is often an inheriting relationship `is-a'
between terms to construct a descending tree of concepts for instance a term `Blood Pressure' is-a
`Vital Signs'. The third and most complicated kind is a \emph{hybrid terminology system} with
ontological 
relationships between concepts and multiple representations of terms. The Systematized Nomenclature
of Medicine Clinical Terms (SNOMED-CT) \parencite{sno2008manual} is considered as a large and complex terminology system that
covers many clinical area. Listing \ref{sno-toes} is a SNOMED-CT example that
uses codes from such a system to form a complex clinical expression of `a burn between the toes': 


\lstset{basicstyle=\ttfamily,
stringstyle=\ttfamily
}
\begin{lstlisting}[caption={SNOMED-CT coding for `A burn between the toes'}, label=sno-toes]
284196006|Burn of skin|: 
        246112005|Severity|=24484000|severe, 
        363698007|Finding Site|=(113185004|Structure of 
        skin between fourth and fifth toes|:
                 272741003|Laterality|=7771000|left) 
\end{lstlisting}
A diversity of codes or terms from different clinical terminologies is used in EHR applications. A
basic scenario as shown in Figure \ref{terminology}, which illustrates an example of EHR systems that involves
transmitting coded information using clinical terminology and looking up descriptions on the
receiving end.

\begin{figure}[!htbp] \begin{center} \includegraphics[width=\textwidth]{../res/terminology.eps} \end{center}
 \caption{An example of using terminology in an EHR application} \label{terminology}
\end{figure} 

Other fundamental usages include rendering the code into a human readable description, 
a preferred term in the context of an EHR application view and translation for a foreign language.
Many clinical terminologies are continuously evolving and there are additional functionalities being
added on newer generation of terminology \parencite{cimino1998desiderata, chute2000cliniclass,
bodenreider2006bio}. For example EHR systems
may rely on clinical terminologies to interact with decision support systems. Logical reasoning and
inferring can be performed on clinical data by using the embedded codes and terms from standard
terminologies \parencite{bodenreider2008bioterm, musen2006clinical, teich2005clinical}.






\section{Modern two-level EHR standards} 
\label{sec:2lvlehr}
Modern EHR systems have come a long way to their current state in developing technologically viable
solutions; in particular, communication protocols, comprehensive system design models and service specifications.
This section covers different EHR standards that are
published by various organisations.  Clinical information that is stored in heterogeneous clinical 
systems may only comply with its own data structure but these EHR standards provide a mechanism for
communicating EHR information based on a commonly agreed health information model.  
%The emphasis of
%this section is to look at a new paradigm that has been developed to produce modern EHR: a two-level
%model EHR.  
First introduced in section \ref{sec:the-problem} in chapter 1, a two-level model based EHR is an 
emerging paradigm in modern EHR standards. A two-level model EHR has a number of 
advantages over traditional clinical record systems. One clear advantage is the 
separation of the basic medical information
that has been referred to as a \emph{Reference Model}, and the domain knowledge, which allows the system
to maintain a relatively stable schema (the reference model). The domain knowledge representation
has the flexibility to change and adapt as medical knowledge advances or changes need to be made to
the system. One significant characteristic of the domain knowledge representation in a two-level
EHR is the idea of expressing clinical content by pre-defined templates. Each EHR standard has
different definitions of such templates, which will be discussed in the following sections.
Although many information models or record standards can be
generally considered as a two-level electronic record, this thesis particularly focuses on a
set of EHR standards that have a clear adoption of the two-level model methodology.
Specifically, the two-level model EHR standards that are discussed in this thesis contain a modelling
mechanism that allows healthcare experts to create the clinical concepts that form the basis of the
information system.
%todo--more

\subsection{EHR information model} 
The goal of adopting electronic health records (EHR) is to
provide sharable, high quality computerised clinical data for the improvement of healthcare. In
order to capture clinical data and build such clinical record systems, proper information models
that concern the health activities must be built. The creation of EHR information models is a
delicate job and requires much domain expertise. Unlike other data modelling tasks, such as building
an information model for an online book store, the modelling of an EHR requires substantial 
domain knowledge
about medicine and healthcare activities such as the work flow of clinical procedures.

Information modelling is a concept from software engineering. During the development of a system, an
abstract model should be built to describe the data structure and specification of that
system. The term ``EHR information model'' in this thesis refers to the 
specification of what constitutes an electronic health record. In a so called two-level
model EHR, there are distinctively two separate layers in the information model. 
One layer consists of clinical
information that will be commonly used by the EHR system but in a range of health contexts. 
For example concepts such as ``Numeric value'',
``Document'', ``Procedure'' are more or less stable and universal, thus a \emph{Reference Model}
that is made up of those concepts is created as a base of an EHR system. The second layer however,
concerns more detailed information that are domain specific. For instance, ``Discharge letter
document'', ``Blood pressure measurement'' and ``Hip replacement procedure'' are information that
contain information of different specialities. This information may differ from department to
department, hospital to hospital, or even device to device. The second layer provides a mechanism to
model this information properly and is made compatible with the EHR system. A clear advantage of the
separation of layers is that clinicians are more likely to agree on the basic concepts. Therefore, systems that
implemented the reference model will find it easier to communicate (based on the same or similar reference
model), while the domain specific information can be modelled by the second layer to fit different
clinical settings and scenarios. 

In general an EHR information model is a structured way to represent clinical information. 
EHR information modellers create concepts as abstraction of
the information in health domain. Standardisation bodies such as ISO/CEN aim to produce EHR
information model standards that can be widely adopted by implementers of EHR systems. The following
sections discuss the notable standards in the field respectively: ISO/CEN 13606, openEHR, HL7. 




\subsection{ISO/CEN 13606} 
\label{sec:cen13606}
The five-part ISO/CEN Standard EN13606 \parencite{iso13606-1,iso13606-2,iso13606-3,iso13606-4,iso13606-5}, is an EHR
standard published by the Technical Committee 251 (health informatics) of the European Committee for
Standardisation (CEN/TC251) and now also adopted by ISO as an International Standard (IS). 
Also named \emph{EHRcom}, which stands for Electronic Health Record
Communication, the five part standard aims to enable the exchange of electronic health records
between different EHR sites.  Started as an European pre-standard, the development of EHRcom has
been influenced by the openEHR EHR specifications. Designed as a two-level EHR model, EHRcom
adopted the archetype methodology to allow clinical experts to model an EHR. In a summary, the five
parts of the standard include a reference model, the archetype model, Reference archetypes and term
lists, security information, and a service interface for exchanging EHR extracts
\parencite{dipak2006ehrstds}. This ISO standard shares many similar characteristics with a community
based standard called \emph{openEHR} which will be introduced in the next section.
However in contrast to openEHR's relatively large and complex reference information model, the EHRcom
reference model has defined an information model with a smaller set of classes that are sufficient for
information communication in healthcare
\parencite{dogac2005ehrstdsurvey}.
Although modelled independently, various elements of the reference model have a similar structural
style with the openEHR reference model. Figure \ref{fig:rmclass} is a Unified Modelling Language (UML) 
\parencite{rumbaugh2004uml} diagram of the main classes of the EHRcom reference model
\parencite{duftschmid2010extr}. A number of back bone classes can be extracted from the diagram, which are
\emph{EHR\_Extract},  \emph{Composition}, \emph{Entry}, \emph{Item}, \emph{Cluster} and
\emph{Element}. The corresponding classes also exist in the openEHR reference model, which play similar roles in
principle. The next section provides a detailed discussion about the openEHR reference model
classes. Because of the similarity and compatibility of the EHRcom and openehr reference
model, mappings could be made to translate meta-data that are expressed in EHRcom format to openEHR
format \parencite{martinez2010mapping}.
Part 3 of the ISO 13606 standard also gives examples of archetypes that can map reference model
classes to HL7 information classes. Researchers have been mapping ISO 13606 archetypes to the HL7
model in studies such as \parencite{goossen2010ehrcomhl7}.

\begin{figure}[!htbp] 
  \begin{center} \includegraphics[width=\textwidth]{../res/rm13606.eps} \end{center}
  \caption{A UML diagram of Reference Model classes defined in ISO/CEN 13606} \label{fig:rmclass} 
\end{figure}



\subsection{Specifications of openEHR foundation} 
\label{sec:openehr}
The openEHR foundation \parencite{kalra2005openehr} is a community that seeks to facilitate the development of open EHR standards. 
A number of technical
specifications have been produced and published by the openEHR foundation including a reference
information model for an EHR, a clinical modelling language called Archetype Definition Language
(ADL), and documents that
specify details of other EHR related technology \parencite{openehr2008over, openehr2008im,
openehr2007aom, openehr2007adl}.  
Started as the Australian GeHR initiative \parencite{blobel2006hl7,blobel2006advanced}, the
openEHR foundation continues the development of standards and technical specification for world wide
adoption of EHR.  openEHR \parencite{sanroma2006survey} has significant influence over the development
of EN13606. 


\subsubsection{Archetypes}
\label{sec:archetypes}
The specifications produced by the openEHR foundation have introduced a new concept,
called the \emph{Archetype Object Model}, which plays
a key role in the openEHR standards to build up a two-level EHR system \parencite{garde2007towards,
garde2007express}.  The EHR
specifications produced by the openEHR foundation define archetypes as a sharable, 
reusable clinical knowledge
representation, a maximum dataset of domain concepts.  The Archetype Definition Language (ADL) 
\parencite{openehr2007adl} was created to allow clinical experts
to design archetypes and share domain knowledge in order to build interoperable EHR systems.  Archetypes as a
mechanism to separate the domain professional knowledge from technical implementation is seen as a
major advancement in developing sharable EHRs \parencite{knaup2007shared}.  


As mentioned in section \ref{sec:cen13606},
the EHRcom standard and the openEHR specifications introduce the architecture of
a two-level model based EHR. The first level, which is called a `Reference Model', is designed to represent a set
of fundamental concepts that are relatively common across all health specialties and scenarios. The
Reference Model includes general and reusable structural elements such as \emph{Folder},
\emph{Composition}, \emph{Entry} and \emph{Element} which can be used to represent physical record
structures. It also contains other commonly used concepts that simulate the information related
the paper based record such as 
associated participants, time stamp and purposes. These general concepts are the basic building
blocks of the EHR. All clinical information or data entries that are captured will be created and
persisted using these building blocks. Different standards or systems will have different
definitions of their reference model. For example EHRcom has a simpler reference model while openEHR
and HL7 reference model have relatively more complicated specifications to represent health data
structure. 


The next level in the two-level model approach is a flexible \emph{Archetype Object Model}
\parencite{beale2002archetypes} that
specifies and organises the detail of what is available in the reference model. An archetype defines
a maximal recordable information set that can be reused by health professionals in various medical
scenarios. It contains constraints of instances in the Reference Model to produce specific meaning.
An archetype can be used to specialise an Entry from the EHRcom/CEN13606 reference model into a
Blood Pressure Observation Entry. The blood pressure observation entry archetype specifies the
reference model concepts and attribute values needed to construct an entry about a blood pressure
measurement. 


An archetype is usually designed by medical domain professionals who define a maximum dataset for
the clinical information that need to be recorded in the EHR \parencite{openehr2007aom}. 
For example, an archetype for
\emph{Symptom of Pain} is designed to be reused anytime knowledge about pain symptoms needs be composed and
committed to an Electronic Health Record. 
% check for duplicates
A key feature of the two-level model approach is the
separation of clinical domain knowledge from technical implementation. It is anticipated that this
separation will ease the development and integration of EHR systems and greatly reduce the cost of
re-implementation and system integration. A more important purpose of defining archetypes is to
permit national or international standardisation of the representation of medical knowledge across
different EHR systems. Therefore archetype-enabled systems will contain standards compliant high
quality health data rather than self-defined and relatively unconstrained health information that
might be less meaningful and helpful to another EHR system.

Figure \ref{bp} shows a \emph{mindmap} \parencite{farrand2002mind} that visualises 
\begin{figure}[!htbp] 
  \begin{center} \includegraphics[width=.7\textwidth]{../res/bp.eps} \end{center}
  \caption{The mindmap of Blood Pressure archetype} \label{bp} 
\end{figure}
an archetype that models the
clinical information about the recording of systemic arterial blood pressure
measurement\footnote{Taken from \url{http://www.openehr.org/ckm/}}. 
Each node specifies a data point that is represented by the appropriate reference
model class in the openEHR specifications. As a reusable EHR artefact, this knowledge representation
can be shared among clinical experts to exchange information. The modelling of archetypes is via the
use of a dedicated modelling language called the \emph{Archetype Definition Language} (ADL). 
The ADL version used in this thesis is the stable version 
$1.4$. ADL version $1.5$ is the latest version of the modelling language which is under
development\footnote{The draft version of the specification is available:
\url{https://github.com/openEHR/specifications/blob/master/publishing/architecture/am/adl1.5.pdf}}.


The following screenshot is a fraction of the raw ADL of the Blood Pressure archetype in Figure
\ref{bp}. Figure \ref{bp_adl} 
\begin{figure}[!htbp] \begin{center}
  \includegraphics[width=\textwidth]{../res/bp_adl.eps} \end{center} 
  \caption{The raw ADL file of the Blood Pressure
  archetype} \label{bp_adl} 
\end{figure} 
exemplifies the ADL syntax and the grammar of the language.
Although the syntax of ADL will not be explained in great detail, the example here shows how such
an archetype is put together. This snippet corresponds to the ``Data'' section of the archetype.
The upper-case names denote the reference model classes: \emph{OBSERVATION}, \emph{HISTORY},
\emph{ITEM-TREE} etc.  It is not distinguished in Figure \ref{bp} that different nodes are of
different reference model classes. What also is not shown in the mindmap is the constraints for
each node. For instance, the value for data node ``Systolic'' is specified by a
``C-DV-QUANTITY'' object, which is a data type constraint instance that confines the value to be
between ``0.0'' to ``1000.0'', with units ``mmHg'' etc. These constraining information will be used by the
real time EHR system to represent clinical information properly.

\subsubsection{openEHR templates}
There is another type of constraint format called openEHR \emph{templates} based on
archetypes. The openEHR specification defines templates as groupings of archetypes to construct a
particular medical document or form. Comparing to archetypes, which are re-usable data items that
constrain on the reference model, templates define the content of a medical document such as a GP
referral by utilising multiple archetype. Currently there are not many example templates available.
Templates can be built for specific projects by using tools from the openEHR community
\parencite{leslie2008international, brazil2010jnc7}.

Templates are introduced as an implementation artefact that can be used to
aggregate archetypes to form a base of a specific medical task such as a data
entry form. Compared to archetypes, templates contain more detailed data
structures that can be used in the implementation of an EHR system. Templates
are comprised of relevant archetypes to assist the creation of an end user
graphic interface.  The purpose of a template is to provide a mechanism for
system developers to select and aggregate archetypes to construct a data
structure that can be easily used in implementation. The difference between
archetype and template modelling language is that the latter is more focused on
pragmatic implementation of the medical information in a real EHR system. It
has been said that templates are the proper place to add terminology bindings
as they are specific to particular scenarios and settings, and so for instance
the actual terminology becomes more certain.  Members of the openEHR community
have asserted that Templates can be used to store SNOMED-CT bindings. For this
reason, during the course of the project, attempts were made to acquire
templates with their bindings which could (it was thought) provide additional
``gold standard'' binding information for the study in chapter 5. However there
are very few number of templates that have been shared with the community and hence the pursuit
of utilising templates is intended for future work.


\subsubsection{Archetype repository}
\label{sec:repo}
An archetype repository provides storage and manages the life-cycle of composed archetypes. The
repository primarily provides the facilities to maintain archetypes and enable the users to keep
track of the inheritance and versioning of archetypes. 

Table \ref{arch_repo} lists some archetype repositories \parencite{nhs_repo, openehr_ckm_repo,
nehta_ckm_repo, sweden_ckm_repo, moner_ckm_repo, brazil_ckm_repo}
that are available in the public domain. It is
clear that more and more projects are involved in using and developing archetypes. It is not
surprising to observe the growth of the numbers of archetypes in these repositories. 


\begin{table}\footnotesize
\begin{center}
  \begin{tabular}{l l l}
    \textbf{Repository name}& \textbf{Description} & number of \\
    & & archetypes \\
\hline

NHS archetype repository&   NHS Connecting for Health project & 650\\

\emph{open}EHR CKM*&    The central repository of the openEHR foundation & 363\\

NEHTA CKM&    The Australian NeHTA (National e-Health Transition & 179\\
 & Authority) repository & \\ 

Swedish CKM&  The Swedish Association of Local Authorities and & 37\\
 & Regions repository & \\ 

EN13606 WG archetypes &  The EN13606 work group archetype sets for CDA & 5\\
Brazil JNC7 archetypes &       The Brazilian archetype implementation of a list of & 31\\
 & JNC7 clinical statements & \\
\hline
*Clinical Knowledge Manager & &

\end{tabular}
\end{center}
\caption{Archetype repositories in different countries}
\label{arch_repo}
\end{table}

The first repository shown in the table, the NHS archetype repository was the result of a pilot
study in the UK's National Health Service (NHS) to evaluate the applicability of the archetype
approach. By the end of the initial phase of the project, 250 archetypes had been created. At the
conclusion of the project in 2007, a total of 650 archetypes have been created to cover selected
clinical areas such as emergency, maternity and mental health \parencite{leslie2008international}. 

The openEHR Clinical Knowledge Manager (CKM) is a collaborative archetype modelling platform produced by
Ocean Informatics \parencite{ckm2012man}. It is
also considered the first instance of CKM running to allow collaborative archetype management.
Currently the statistics show that 322 archetype reviewers and more than 1000 interested persons
from over 60 countries use the system. A total of 363 archetypes are under the process of being
drafted, reviewed and published at time of writing in August 2013. This collection of
archetypes is considered by many to be the most mature public archetype repository and many of the
archetypes are refinements of archetypes that were originally developed during the NHS project.

The Australian National E-Health Transition Authority (NEHTA) is also running an instance of CKM
that aims to engage clinicians, informaticians and other domain experts in the health community in
the development of archetypes. The archetypes in the NEHTA repository have been developed based on
clinical best practice and are intended to be the building blocks of various e-health solutions. The
archetypes in this repository employ a slightly different style to the archetypes in the openEHR
CKM. 
%For instance, they have more use of IDs [ref Damon PhD].

After the decision made by the Swedish County Councils, a national project was initialised to
investigate EN13606 standard and openEHR archetypes \parencite{sweden2012strategy}.  
The Centre for eHealth in Sweden runs a CKM
instance to maintain and manage archetypes produced by a group of healthcare professionals and
informaticians. There are 20 clinical archetypes and 17 demographic archetypes maintained by the
repository. 
%[ref Damon PhD].

New archetypes have been submitted to the EN13606 work group website as a result of a collaboration
mentioned in \parencite{moner2012cda}. Alberto Moreno from the Hospital Virgen del Roc\'{i}o in Seville
created these archetypes to model nephrology data.


In a Brazilian national health informatics project \parencite{brazil2010arch}, a set of clinical statements and
guidelines have been mapped to archetypes that were extracted from the openEHR and the NEHTA
repositories. A total 31 archetypes have been developed based on these archetypes to cover medical
conditions such as hypertension. 

There are already studies pointing out that overlaps between these repositories bring difficulty for
projects that wish to adopt archetypes. The similarity and differences of archetypes from different
developers might make it not easy to decide which one to use \parencite{brazil2010jnc7}. The
Venn chart in Figure \ref{venn} shows the overlaps and the number of unique archetypes in the three 
repositories: the NHS, openEHR and NEHTA archetype repositories. 
\begin{figure}[!htbp]
\begin{center}
\includegraphics[width=0.7\textwidth]{../res/arch_comm.eps}
\end{center}
\caption{Venn diagram of the overlaps and differences of the archetypes in three repositories}
\label{venn}
\end{figure}
It has also been noted that new archetypes are made in a country-specific context where the existing
archetypes can not meet the need of national projects. For example a Danish national project
produced special archetypes to map different clinical models \parencite{bernstein2005modelling}.



\subsubsection{Life cycle of archetype modelling} 
\label{sec:lifecyc}

Archetypes are expected to go through a life cycle
from creation to publication with clinicians reviewing and improving the quality of archetypes. The
management of archetypes is documented in the openEHR specification \parencite{openehr2007mgmt,
openehr2007cycle}. It is important to understand this process because archetypes will be carefully
chosen for this work.
%todo -- add ref similar archetypes in repos e.g Brazilian arch paper
% e.g openehr ckm took more mature ideas from NHS repos, health informatician, swedish more on
% demongraphics, find the CDA templates



All archetypes that are committed into the repository should follow the naming convention 
that is defined in the specifications for the Archetype
Object Model.  The naming scheme allows generic archetypes to be extended by more specific
archetypes. To extend an archetype, the resulting archetype must inherit information in its parent
archetype and add more specific clinical content. In Figure \ref{inheri}, a generic symptom
archetype has been extended to be 
a pain symptom archetype with more specific
clinical details. Versioning is a mechanism which allows different versions of archetypes co-exist
for the purpose of tracing their editing history as the development goes on. The latest version is
assumed to be most mature in quality and content. As Figure \ref{inheri} demonstrates, both
inheritance and versioning produce duplicate counts for the same archetype term which will be
removed in the archetype term extraction process. The versioning and specialisation are part of the 
archetype management strategy for sustainable clinical model development \parencite{hovenga2010archmgmt,
garde2007managing}. 



\begin{figure}[!htbp]

\begin{center}
\includegraphics[width=\textwidth]{../res/dup_inheri}
\end{center}
\caption{Archetype specialisation and versioning}

\label{inheri}

\end{figure}


\subsubsection{Entry classes}
\label{sec:entrycls}
By design, the EHR information model produced by openEHR resembles the document structures of
clinical documents that are being generated in daily care. In the openEHR reference information
model, an \emph{Entry} is a single clinical statement that describes a medical phenomenon about the
patient. It could contain information from values of measurements to description of diagnosis.  For
example a ``Body Mass Index (BMI)'' entry is about the recording of the ratio of an individual's
body weight to his/her height.  



The openEHR reference model specification has a distinctive way of organising 
part of the electronic health record that is referred to as an \emph{Entry}. 
As a generic component that can be
found in many EHR models, an \emph{Entry} usually represents the information that is entered by the
clinician to record an event or statement about the patient. Essentially an \emph{Entry} is a class in the
reference model, presenting a generic type of ``clinical statement'' that can be recorded in a
clinical document.
In the openEHR reference model, \emph{Entries} are
divided into more specific subtypes. These subtypes include five different types of entry according
to \parencite{openehr2008over}:\emph{Admin\_entry}, \emph{Observation}, \emph{Evaluation}, \emph{Instruction} and
\emph{Action}.  They are more specific than the generic \emph{Entry} class but are also general
enough to be reusable as information containers. 

The design of subtypes of the \emph{Entries} reflects openEHR's philosophy that clinical information
should be categorised accordingly with respect to the clinical problem solving process. 
Figure \ref{fig:examofontomodelinmeddom} represents openEHR's view of clinical
information flow \parencite{openehr2008over}.  Information in the cycle of health care are typically divided into four
categories, each represents a stage in the care flow and the clinical information to be captured by
an EHR.  The five subtypes of \emph{Entry} resemble the information in this care flow that are
provided by health professionals. An analysis of the openEHR entry model shows that the entry
classes are realism-based and specific for medicine \parencite{andrade2011entry}. 
For example, among all recorded information, observation-related
information such as patient problem history, diagnosis and assessment can be captured using the
\emph{Observation} class. Intervention-related information such as investigation request should be
captured using \emph{Instruction} class.  
\begin{figure}[!htbp] \begin{center}
  \includegraphics[width=0.7\textwidth]{../res/openEHR_info_cycle} \end{center} \caption{Example of ontological
  modelling in medical domain. } \label{fig:examofontomodelinmeddom}
\end{figure} 
% todo -- check if UML has introduced
Figure \ref{entry_uml} is a UML diagram that shows
the relationship between class \emph{Entry} and its subtype classes. The diagram indicates that
\emph{Observation}, \emph{Evaluation}, \emph{Instruction} and \emph{Action} are subtypes of the
\emph{Care\_entry} class, which is modelled to distinguish with the \emph{Admin\_entry} class. 

It is worth noting that the five subtypes of \emph{Entry} class are not enough to capture all
clinical data. Clinicians tend not to think in relation to these classes when documenting care.
Modelling more specific information and the diversity of clinical statements are achieved by using
\emph{Archetypes}.  Archetypes that are created by archetype modellers are able to specify more
detailed clinical information in terms of clinical domain knowledge. For example, a lab request
archetype is an \emph{Instruction} archetype that specifies the details of a request for an
investigation on a patent to be completed in a laboratory.  

\begin{figure}[!htbp] \begin{center} \includegraphics[width=\textwidth]{../res/entry_uml} \end{center}
  \caption{UML diagram of the Entry class in openEHR reference model} \label{entry_uml} \end{figure} 

The reason for enumerating the subtypes of the entry class is to show the decisions that have been
made during the development of EHR standards. These are evidence of effort to make the information
stored in an EHR more
semantically correct by introducing clinical concepts to the data structure of the EHR. The
importance of these new changes in the EHR information model is that it improves the data quality of
the clinical information by providing a semantic context. However these changes also reveal that
there are many issues relating to semantic interoperability when developing a flexible two-level
EHR.




\subsection{HL7 version 3} 

The Health Level 7 (HL7)\footnote{The organisation and its members in
different countries known as
'Working Groups' create and publish technical standards. See \url{http://www.hl7.org/}} organisation is a non-profit 
international standardisation body involved in developing
comprehensive specifications of electronic health records and the associated technology to
facilitate the adoption of sharable EHR \parencite{klein2002std, hammond1995us}.  
The Health Level 7 messaging specifications and its 
Clinical Document Architecture (CDA) \parencite{dolin2006hl7} are popular information model standards
for the medical industry. Its structure includes a mature and detailed model which corresponds to a common
health concept typology. Prior to HL7 standard version 3 HL7 messages do not use an information
model as elaborate as EHRcom or openEHR. Instead it uses a messaging syntax to send electronic messages between systems. 
HL7 version 2.x standards are hence often regarded as messaging standards
\parencite{blobel2006hl7}.
However since HL7 version 3, with the addition of the
Clinical Document Architecture (CDA) specification, the standard underwent fundamental changes and 
is also considered to be an object-oriented architecture and a
multi-level EHR information model \parencite{beeler1998hl7v3}. The HL7 CDA standard is essentially an XML-based
standard for describing or modelling clinical data that is recorded in a clinical document. Hence
the separate layer is a domain knowledge representation, for instance a CDA template for a clinical discharge
letter.



\subsubsection{HL7 information models} 

Over the years since the early conception of its standards,
the information models of HL7 standards have grown bigger and more sophisticated. To describe the up-to-date
family of standards in a nutshell, the main information models of HL7 include the \emph{Reference
Information Model} (RIM), \emph{Domain Message Information Model} (D-MIM), \emph{Refined Message
Information Model} (R-MIM). The latter two are derived from the Reference Information model (RIM).
The HL7 RIM is the core and a static information model for representing clinical information in HL7
messages. The set of base classes are shown in Figure \ref{hl7rim}. It serves a similar purpose as
the reference model in the openEHR and EHRcom standards, which provides the fundamental classes to
express the information content in the medical field. Comparing to the corresponding classes in the
specifications of openEHR and EHRcom, the base classes of the HL7 RIM are intended to represent
more abstract and general concepts. As shown in Figure \ref{hl7rim}, the six base classes
are intentionally generic that they can be used for a wide categories of health related
information. It is worth pointing out the difference between  openEHR reference
model and the RIM, with regard to how a document structure is formed. The openEHR reference model
contains classes such as \emph{Composition} and \emph{Entry} that model a document
structure. While the HL7 version 3 standard uses the Clinical Document Architecture to define a
document structure.  Overall the HL7 information
models endorse a slightly different modelling style: unlike openEHR's reference model, whose classes
are derived from the clinical problem solving process, the HL7 RIM represents a more abstract view
of clinical concepts. The D-MIM, which is a subset of the RIM that includes refined classes to be
used to create messages for a particular medical domain. The R-MIM, in turn, is a subset of the
D-MIM to represent the message content and message specific information. From the author's
observation, the more specific the model is, the more domain knowledge is involved. That is, as
specialisations of the fundamental RIM, the D-MIM and R-MIM have elaborated the clinical details in
their models. The granular structure of these models introduces more intrinsic complexity of
clinical information at each level. For instance, not confined in the RIM, the Pharmacy D-MIM
specifies concepts that can be used relating to drugs and medicine.

% change to UML class diagram
\begin{figure}[!htbp] \begin{center} \includegraphics[width=\textwidth]{../res/RIM_main} \end{center}
  \caption{The base classes of the HL7 RIM} \label{hl7rim} \end{figure} 

Another notable feature of HL7 information models is the use of special attributes to specify the
clinical setting. For example although an ``Act'' class may seem too abstract to represent all of the
elements of clinical actions, a ``mood'' attribute can be used to indicate the purpose of the act:
an activity that has already occurred, can happen, is happening, or is requested. The value of such
attributes is often a HL7 internal code or a standard code from a terminology system. However the
``mood'' attribute is not intended to serve as a status code, different moods of acts are different
instances of information. Many attributes exist in the models to provide clinical meanings,
especially the Clinical Statement Pattern D-MIM, which forms the basis for content information in
CDA \parencite{oemig2005does}.  The ability to reference codes from controlled vocabulary gives the information model
flexibility to adopt different clinical scenarios. However in practice caution must be taken to make
the EHR proper and meaningful. Section \ref{sec:term-equal} will discuss the issues of inconsistency in coding clinical
information and section \ref{sec:terminfo} will discuss the current research targeting at HL7 standards.



\subsubsection{The Clinical Document Architecture} 
\label{sec:cda}
%change acronyms to emph
The Clinical Document Architecture (CDA) is a
clinical document mark-up language standard developed by the HL7 organisation. The standard
specifies the structure and semantics of clinical documents for the purpose of exchange. The
underlying content of the document is based on the RIM and the data types that are specified as part
of the HL7 standard. There are many reasons and motivation behind the development of CDA. The
exchange of electronic clinical information is a challenging task even with the EHR standards. It is
difficult to create future-proof, reusable clinical information that can be shared in a community.
With a large and sophisticated information model such as the HL7 RIM, a human readable and machine
readable format is needed for the purpose of exchanging information. Clinical documents in many ways
have a certain maturity over centuries' development and are a natural source for exchanging.

Typically resembling a document, a CDA file contains a header and a body. The header is comprised of
various meta-data that include information about the subject of care, security, clinical settings;
the body encapsulates the clinical report. The header section in particular describes the semantics
of each entry in the document by referencing the RIM. Being a XML-based standard, CDA does not
specify how documents can be exchanged but rather the format of message. Therefore in reality,
whether the documents are exchanged as text or Multipurpose Internet Mail Extensions (MIME) is left
to the system implementers.

As defined in \parencite{dolin2001r1}, a CDA template is a representation of constraints on the generic
CDA model. The two categories of current implementation of CDA and CDA templates include XML based
technology and programming language specific object models. Similar to openEHR archetypes, a CDA
template can be defined to express constraints on a generic EHR information model. For example a
patient summary can be specified by using a CDA template \parencite{ferranti2006hl7}. Therefore CDA
templates play a counter part of archetypes in HL7 version 3. However, at the
time when this project started there were not sufficient publicly available CDA templates and
repositories similar to the openEHR archetype repository. 

%It was decided that future work should carry out to include CDA templates into the research scope of this thesis.








\section{Clinical terminology} 
It has been mentioned a number of times in the thesis that clinical terminologies are an essential
component in the implementation of an EHR system.
The term \emph{clinical terminology} however, can be used to refer to the controlled vocabulary of terms or codes
, or a sophisticated computer system that provides services to enable other systems to
utilise these terminological resources. This section provides an overview of clinical terminology
systems and introduces a prominent clinical vocabulary named SNOMED-CT. % todo add more?


\subsection{Evolution of clinical terminologies} 
\label{sec:clinicalterm}
%
%The goal of semantic interoperability in the
%e-health domain is an elusive but worthwhile one that both the industry and the research community
%have pursued. In the absence of semantic interoperability, heterogeneous systems have the potential
%to cause integration difficulties and possible mis-interpretation of information during data
%exchange. This is a recurring issue in the current e-health environment. 
%
%
%%todo--change following format and use as quote 
%The SemanticHEALTH project \parencite{SemanticHEALTH2008}  has provided the following definition of
%interoperability.\\ \textit{ ``\ldots Health system interoperability is the ability, facilitated by
%ICT applications and systems,\\ - to exchange, understand and act on citizens/patient and other
%health related information and knowledge\\ - among linguistically and culturally disparate
%clinicians, patients and other actors and organisations\\ - within and across health system
%jurisdictions in a collaborative manner\ldots''\\} They further classify a number of different
%levels of interoperability as follows\\ \textit{ ``\ldots\\ Level 0: no interoperability at all\\
%Level 1:  technical and syntactical interoperability (no semantic interoperability)\\ Level 2: two
%orthogonal levels of partial semantic interoperability\\ Level 2a (quality): Unidirectional semantic
%interoperability\\ Level 2b (quantity): Semantic interoperability of meaningful fragments\\ Level 3:
%full semantic interoperability, sharable context, seamless co-operability\\} As the level of
%semantic interoperability increases, better integrated terminologies are required to address issues
%that arise when data exchange happens between heterogeneous EHR systems\ldots''
%

In contrast to the development of an EHR information model that simulates the data that can be stored as 
a clinical record, symbolic representations of the meaning and context of the clinical
information are developed as ``terminology'' in health care. A clinical terminology is the
terminology relating specifically to topics in medicine. The term has many aliases such as ``controlled
vocabulary'', ``clinical terminology'' and ``coding system''. Terminology in health care is regarded
to be as old as computers, because initially shorthand codes and terms were invented and designed to
minimise disk space usage. For example, a textual description of ``Diabetes Mellitus'' can be
shortened by simply using a term like ``DM'' or even a code that can be understood by the computer.
The history of using codes pre-dates the origin of digital computers. The idea of coding lies in the
use of symbolic or alphanumeric representations to refer to agreed concepts or real world objects.
Terminologies at the beginning served the same purpose as any other codes being used in a computer
system: to save precious memory/disk space and for the ease of processing data. These obstacles are
long gone since the computing power and storage technology has been increasing dramatically. 

The number and size of clinical terminologies are expanding rapidly due to the fact that many reference
terminologies aim to cover the fast growing domain knowledge in medicine.
The introduction of electronic health
records and EHR systems opens the possibility that clinical data capture can be
supported by embedding terminology from terminological systems such as SNOMED-CT to hospital 
information systems \parencite{rosenbloom2006interface}. Given this great potential, electronic health record approaches such as EN13606
provide explicit support for clinical terminology systems. Studies have shown 
\parencite{rector1999why} that the growth in use of coded information and terms and the amount of terminology
training undertaken by healthcare professionals is continuously rising.  Perhaps this is related to
the fact that many forms, screens and coding frames for e-health applications have adapted medical
terminologies and it also reflects the popularity of terminologies among the majority of system
vendors. Huge effort has been invested by these vendors to improve the human computer interface to
cope with terminologies \parencite{zanstra1998coding}. 
%However, perhaps the existing systems with embedded
%medical terminologies have convinced the users to adapt to them without asking why [ref alan r], 
%the modelling of clinical concepts may need to adjust terms that have derived meanings.
% find rector paper




\subsection{The overview of clinical terminologies}


During the expansion and accumulation of our knowledge of medicine, medical terminology has evolved
to allow us to support more clinical tasks. Common functionalities of clinical terminologies 
can be classified into the following categories \parencite{cimino2001terminology}: 


\begin{enumerate} 
  \item Clinical data capture and presentation - letting healthcare professionals
    enter, store, and review what would otherwise be written in the clinical notes 
  \item Information
    integration, indexing, retrieval - linking clinical records, decision support, quality
    assurance, and other information.  
  \item Messaging between software systems - linking laboratory
    and hospital information systems or sending prescriptions from prescriber to dispenser to the
    Prescription Pricing Authority 
  \item Reporting - providing the official returns in whichever
    coding system is required \end{enumerate}




However the need for terminology in medicine did not develop spontaneously. For a long time the use
of natural language was (and continues to be) predominant for clinical note-taking and for other
medical documentation. Natural language is very expressive when used in human communication.
However it does not suit the purpose for the communication between EHR systems. 
Some obvious drawbacks are the ambiguity of human language and
number of languages and dialects worldwide. The words we use to describe a situation or phenomenon
depend heavily on the context. We exchange ideas and meanings in conversation - conveyed by the words. Free
text that is used in health data or clinical note-taking may suffice within a small environment, such
as, personal use or an office. But it soon becomes problematic when health professionals wish to
exchange clinical information. As the desire for exchanging reusable clinical data arose, a
controlled and commonly agreed vocabulary was needed. When people first attempted to classify 
clinical phenomena, they experienced difficulties to produce meaningful descriptions using natural languages:
there are many ways of expressing the same meaning. Meanwhile, using short phrases to describe
a clinical concept may result in different
understanding and interpretation. Codes were developed to resolve
this issue. The difficulty of processing natural language related information has also acted as
a barrier to the rapid development of a meaningful digitised clinical record. By comparison, codes
consist of numbers and letters and so are easy to process. Codes can also reduce risks in health care
by removing ambiguity. In general, the practice of using terminology to encode clinical information is increasing
in many medical fields such as clinical noting, clinical data entry and documentation. 


Looking back in the  history of terminology development, different types of terminology
systems have been created over the last few decades \parencite{cimino1996rev}. 
At the beginning, single purpose code sets were
developed for use in specific medical areas. Examples of these coding systems are the UK READ
codes \parencite{bentley1996structural} and LOINC codes 
\parencite{loincman}. A common problem with a fixed list of terms is that the meaning of a term may change over time due to
the evolution of medicine while the words used do not. It could also be the case that the
description of a medical concept has to change because of new findings. And these
circumstances could occur simultaneously. These issues lead to a solution that introduces a new way
of creating terminology for clinical use: build medical concepts and assign codes to them.


In order to design a medical thesaurus that are based on medical concepts, a vast library of medical 
phrases and descriptions must be collected and mapped to. 
To avoid terms overlapping with each other, a more sophisticated type of code
system is required. Codes or terms in the system exist as concepts. Relationships are created
between concepts to form a classification. International Statistical Classification of Diseases and
Related Health Problems (ICD) \parencite{icd10manual} is an example of this approach. Because each code/term in a release
persisted a concept, the code/term is acting just a symbol of that concept. Multiple releases of
ICD have the advantage of allowing one easily and distinctively identify and specify a concept, for
instance, the manifestation of hepatitis through the history of studying and researching such
disease. However despite the countless clinical terms for describing medical phenomena, many
dialects exist in local use by health professionals. The number of terms and concepts keep expanding
in those classification code systems. A third type of code system emerged: a compositional code
system. In this type of system, each code is a concept of mini-ontology. Expression of new concept
can be composed by existing concepts. The system contains axioms that will not violate the logic of
reality in medicine. A nice feature of this system is to have the ability of inferring and
reasoning. This can greatly facilitate interoperability especially where it requires communications
between electronic systems with no human intervention. Other promising features such as decision
support and AI in health are at the high end of research.  An example of such a code system is
Systematized Nomenclature of Medicine-Clinical Terms (SNOMED-CT) developed by
the International Health Terminology Standards Development Organisation (IHTSDO). A formal knowledge
representation called Description Logic \parencite{schulz2001parts}, specifically $\varepsilon l++$ \parencite{BaaderEL++}, has been adopted when developing
SNOMED-CT. SNOMED-CT is so far the most complicated code system for clinical use. 


To summarise: the effort to produce reusable clinical thesauruses has led to the development of
clinical terminology systems. A clinical terminology like SNOMED-CT is a semantic network of
clinical terms with subsumption relationship that defines phenomena and health-related concepts
\parencite{bodenreider2007investigating}. When
exchanging health related information, the data quality of information recorded in EHR can be
improved by referencing unambiguous concepts from terminology systems. These concepts exist as codes
or terms in various EHR-related applications. Terminological systems can be developed separately by
clinical domain experts who model and build codes that can be used for encoding health information. 






\subsection{The ontology approach} 

Most coding systems cover only a specific area of medicine as
they were designed for a single-purpose. MeSH (Medical Subject Headings) \parencite{lipscomb2000medical} is used
for the purpose of indexing and searching bibliography in medical databases. The 4 digit Read Codes,
\parencite{lowe1994understanding} were designed to be used by general practitioners for disease and service
registers. As mentioned earlier about the evolution of terminology, more recently developed
controlled vocabularies tend to cover more medical concepts than their precedents and they span
multiple purposes. For example, certain codes can be used for both messaging and information
retrieval. New problems arise with the creation and management of bigger and richer terminologies. 




\begin{itemize}


\item Standardisation for share and re-use: Because of a need for larger terminologies to support
  multi-disciplinary care, merged sets of medical concepts are required to be logically correct and
  coherent. Concepts from different classification systems, which when viewed independently, were
  considered logically correct, may appear to be incorrect when brought together, due to differing
  classification methods. In addition, where classification systems overlap, a single concept can be
  classified in different ways in the original code systems. In order to address these problems,
  re-modelling of all the concepts may be required. The cost in terms of time and resources is a
  major barrier to the release of a mature and practical merged terminological system. Each time a
  terminology is modified and expanded, another iteration of re-modelling may be necessary. When
  building a large and coherent terminology, any modification of a basic feature of the
  classification has the potential to cause a significant change. 
 
\item Problems of expressing the item to a corresponding code: It is often discovered that in real
  medical circumstances, an item does not exactly correspond to the code in the terminology. This
  may be because: \begin{itemize} \item the item is not classified or identified.  \item the item is
      not classified in a way that a user recognises.  \end{itemize}


So in order to map the item to a code in the terminology a new code has to be introduced. However
this cannot guarantee that, 
\begin{itemize} 
  \item the new codes can cover all the gaps in expressing
    variants of the item and 
  \item the new codes do not collide with the old codes.  \end{itemize}
\end{itemize}






This effect tends to make the offending parts of a code system unmanageable. Since the introduction
of codes, the expressivity of terminology has been the primary concern when developing new
terminologies. Difficulties have arisen when mapping a concept to an appropriate code in a
terminology due to many classification approaches. To address this problem, a method of expressing
the same concept in different ways should be allowed in single terminologies. 
 
This is where \emph{ontology} comes to aid the development of modern terminology. A brief
definition of 
ontology in the flavour of medical information science is \emph{a formal representation
of knowledge in a domain of medicine by a set of concepts and their relationships}
\parencite{cimino2006onto, smith2003ontology}.
Ontologies use classes to describe groups of entities that inherit similar features  
and attributes that describe the properties and characteristics. There are other
components such as relationships and assertions. Ontologies have been used to model
specific domains in medicine, such as anatomy and diseases. 
 
The primary motivation for the application of ontologies to information science is to enable
computer-based reasoning. Medical information science takes advantages of ontology in various ways
to enhance reasoning technologies such as decision support systems,
population health surveillance and others. Two distinct approaches are being used to develop strong
links between terminologies and information models. 
 
Object oriented modelling: Ontology facilitates more coherent modelling by allowing an information
modeller to assign formal meaning to different types of information. For example, consider the
introduction of ``Class'', ``Object/Instance'', ``Attribute'' and ``Relationship''. These basic
elements provide a paradigm for designing and modelling many specific domains including the medical
domain. 
 
Hierarchical modelling: Another design pattern that has clearly influenced modern terminology is to
conceptualise pieces of medical information and link them in hierarchical structures. This practice
allows the term or code to be referenced in a medical document while it resides in a network of
concepts which reflect reality. It also provides the opportunity for standardising the concept
network so that the use of terminology always closely follows reality. 
 
One feature of ontologies is that there are multiple representations of a complex concept. When
this approach is applied to terminology, it permits medical concepts to be composed by different
codes that act as smaller components of a bigger concept. While this composition property is not yet
widely used in practice in health terminology, it does help to address the problem mentioned above
of merging an ever growing list of codes into very large collections of terms. 
 
Certain logic can be applied to assure the correctness of these composed expressions to minimise the
number of codes. An example of a coding system which has this capability is SNOMED-CT and the logic
used is Description Logic \parencite{rector2008hard}. 
 
Ontologies also influenced the development of EHR information models. Because the EHR presents as a
structure to record clinical information to form a consistent electronic artefact, the resulting
recording should be medically meaningful. The electronic equivalent should make sense in the medical
field, for example a recording of observing blood pressure should become a ``measurement'' or
``observation'' but not ``evaluation''. To ensure such logical coherence, the design process needs
to take ontological aspects into account. Figure 2 gives an example of how these views can impact on
modelling in the medical domain. Major EHR information models have mature implementations of
ontological views of medical domains yet a lot of effort is spent to elaborate them. 
  

However there exist many views of how the clinical information ought to be modelled. Sometimes these
views were generated by survey or requirement based on a particular profile. Data stored in
hospitals are significantly more complex than smaller clinics.  As described in section
\ref{sec:entrycls},
Figure \ref{fig:examofontomodelinmeddom} is only a generic view of how to classify clinical
information at an abstract level \parencite{beale2007ontology}.  Different ontological views lead to
different results of modelling. One proof is the subtle differences found in building blocks of EHR,
reference models of many standards \parencite{khan2012mapping}. 
 
The archetype approach involves the use of a constraint model which allows specifying clinical
content (also is regarded as clinical domain knowledge) that to be recorded in an EHR. The constraint model employs a
structure similar to a biomedical ontology such as SNOMED-CT, which contains concepts, attributes and relationships. Extended work is already
on the way to expand ADL to ontology authoring language such as OWL \parencite{bicer2005archetype}.
Meanwhile, ontology influenced terminology such as SNOMED-CT is becoming more predominant.
Collaboration between openEHR and IHTSDO to harmonise some aspects of both information model and
terminology is being carried out recently. It was announced in September 2009 that openEHR and
IHTSDO will partner to facilitate effective and sustainable clinical content for electronic health
records\footnote{News feed: http://www.ehi.co.uk/news/EHI/5218}. Movement towards an ontological
structured EHR could be a future development direction.






\subsection{SNOMED-CT} 

Among all the clinical terminologies, SNOMED-CT (Systematized Nomenclature
of Medicine-Clinical Terms) is a sophisticated standard controlled clinical vocabulary. Its top
categories cover many medical terminology groupings such as clinical procedure, diagnosis, anatomy,
organism, physical objects and so on. It has also been gaining popularity in the EHR field as many
EHR information models provide mechanisms to integrate with SNOMED. The main reason for singling out
SNOMED-CT is because:


%check s/SNOMED/SNOMED-CT/
\begin{itemize} 
  \item The scope of SNOMED-CT is similar to the scope of clinical archetypes. Concepts
    in SNOMED-CT have many equivalents in archetypes. The demand of integrating archetypes with
    SNOMED-CT is high. A data set of existing links in archetypes exists.  
  \item SNOMED-CT supports
    post-coordination which is a way to compose complex clinical statements by aggregating
    individual concepts in a structural style. This gives the terminology the ability to construct
    `new' concepts with constrained or refined meanings.  
  \item The mappings of other terminologies
    to SNOMED-CT are under intensive development and there is a high expectation of success in this
    work.  
\end{itemize}




\subsection{Ontologies and SNOMED-CT}
%check is-a 
\label{sec:ontosno}
The development of medical ontologies requires both
effort from clinical domain experts and information scientists. One benefit of using ontologies is
to be able to reason whether statements are correct or not logically. As introduced earlier in this
chapter SNOMED-CT is a large ontology based clinical vocabulary. It is a network of linked nodes that covers
over 300 thousand clinical concepts. Although not optimised to be visualised as a graph
, SNOMED-CT is a large medical ontology with concepts represented as nodes in a network structure.
Given that all concepts in the SNOMED-CT hierarchies have been linked by the \emph{IS-A}
relationship, it makes SNOMED-CT a large taxonomy and a tree structure.
\begin{figure}[!htbp] \begin{center} \includegraphics[width=\textwidth]{../res/snomed_in_termviz}
\end{center} \caption{ The network of SNOMED-CT concepts} \label{SNO_termviz} \end{figure}

Figure \ref{SNO_termviz}  shows that the SNOMED-CT concept network is a directed
acyclic graph (DAG) \parencite{lussier2007clinical}. The idea of imposing the
directed acyclic graph structure into terminologies was originally proposed in the 80's
\parencite{cimino1989designing}. Although ontologies and graph theory are not the focus of this thesis, certain concepts 
have been adopted and utilised in this work, such as semantic similarity \parencite{pesquita2009semantic} and
lowest common ancestor \parencite{aho1973lca}. 
Among characteristics of medical ontologies, semantic similarity is of vital importance to biomedical
researchers who need to compare gene functions \parencite{sevilla2005correlation}. 
The Gene Ontology (GO) is a biomedical ontology that in particular can be used to annotate
characteristics of gene products. It provides a large library of terms that are used in molecular
biology \parencite{ashburner2000gene, smith2003go}.  
Semantic similarity
in medical ontologies measures the degree of relatedness between two entities by meanings in a given
ontology \parencite{lord2003investigating}. 
%If they are considered semantically identical, they can be called as semantically equivalent [ref].

%insert text re sno structure fig in paper2
Figure \ref{SNO_termviz} also illustrates the overview of the SNOMED-CT hierarchical structure. As shown in
the diagram, `SNOMED-CT' is the root node of all concepts and the parent node of abstract 
categories such as \emph{Body structure} and \emph{Clinical finding}. Each
category represents an abstract clinical classification, which are sub-classified in turn by
more descriptive and specific categories. Table \ref{sno_report} lists the information for all 19 first
level categories of the SNOMED-CT release that was used in the study.  
%The numbers indicate the
%size, i.e.\ the total number of concepts under a first level category, which are listed in
%descending order.  All concepts have been indexed %mv to other sections 
%and stored in our database for the mapping process. 
Second level categories are further sub-classified. This
structure continues further down the concept hierarchy until the most specific concepts are reached. The
SNOMED-CT concept model allows multiple-inheritance, for example \emph{Disorder by body site} can be
both the child of \emph{Disease} and \emph{Finding by site}.


\begin{table}[!htbp]\footnotesize \begin{center} \begin{tabular}{ |l| }
  \hline
  \textbf{First level category name} \\
  \hline
  Clinical finding (finding)\\ 
  Special concept (special concept)\\
  Procedure (procedure)\\
  Body structure (body structure)\\
  Organism (organism)\\
  Substance (substance)\\
  Pharmaceutical / biologic product (product)\\
  Qualifier value (qualifier value)\\
  Event (event)\\
  Observable entity (observable entity)\\
  Social context (social concept)\\
  Situation with explicit context (situation)\\
  Physical object (physical object)\\
  Environment or geographical location (environment / location)\\
  Linkage concept (linkage concept)\\
  Staging and scales (staging scale)\\
  Specimen (specimen)\\
  Record artifact (record artifact)\\
  Physical force (physical force)\\
  \hline
\end{tabular} \end{center} \caption{First level categories} \label{sno_report}
	       \end{table}

\section{Summary}
This literature review started from the perspective that aimed to cover a comprehensive area in addressing the problem of linking clinical information with standard terminologies. Other projects have focused on a specific problem that is associated with specific technologies and methodologies. The investigation of the literature undertaken by the author has taken a wider perspective that observes many related issues and seeks to find and therefore build upon a systematic solution. But no such systematic approach was encountered in the literature.   


% note that the CDA template repository was not mature when the review was done 3 yrs ago so the decision was made to use a resource that was mature at that time.  “it” ??? was incorporated in the studies, same as openEHR templates, mention the investigation of these repos, the life cycle, history, content etc


Chapter 2 \emph{Background of the research} has provided an overview of the contemporary and forward-looking EHR and clinical terminology standards and projects. 
A review of the state of art technology of integrating clinical information model with clinical terminologies was also provided in chapter 2. For instance section 2.2 gave a review of the current specifications and standards of EHR and clinical terminologies. The review provided evidence that the integration between EHR information model and clinical terminologies has a lot of benefits and advantages for healthcare professionals and clinical researchers.


The benefits can be summarised by the following categories:
\begin{enumerate}[(a)]
  \item Securing patient health safety by delivering high quality clinical information
  \item Reducing ambiguity in semantic meanings of clinical information
  \item Building flexible and re-usable clinical information systems
\end{enumerate}


% ADD sentences in ch 2, why the review is special, what's the point


% mention it in chapter2 EAV is a general approach, cite Damon’s thesis


Section~\ref{sec:related-work} in Chapter 3 looked at a number of integration approaches and the related projects that explored the associated research territory. It was concluded that a specific study on examining the relationship between an EHR information model and terminologies and enhancing the integration paradigm was needed to facilitate the building of a semantic EHR. The author was motivated by this finding and has conducted the study that is reported in this thesis.
The survey of the literature has not been limited to health informatics. It also extends to other
areas that the author believes may have potential influences on the research problem that this
thesis attempts to solve. For instance the discussion of the origin of clinical terminologies and
the emergence of ontology may have explained why there is an integration issue between EHR
information models and terminologies. Section~\ref{sec:eav} also discusses a generic modelling
principle called ``Entity-Attribute-Value'',  and an evolution by  Nadkarni et al called EAV/CR
\parencite{nadkarni1999eavcr}
which as noted in \parencite{dbPhDthesis} shares common features with two level models and could inspire future development of health information models. 



%\end{document}
